Fix #1124: close the pre-steal-inode race, inode-reuse/non-preserving-rename gap, and hand-back clobber in _lock_try_steal - #1126

Summary

Three self-contained fixes to _lock_try_steal / _lock_file_inode / hand-back in
scripts/lib-lock.sh, closing the three paths #1124 found after #1123:

1. Pre-steal inode snapshot timing -- the "before" inode was captured after the first
   pid read and the age check, leaving a window where a racing contender's full
   steal-and-rewrite cycle could land and be mistaken for the unchanged original
   placeholder, producing two simultaneous holders. Fixed by moving the snapshot to the
   top of the function, before the first read.
2. Rename does not preserve inode identity everywhere -- _lock_file_inode assumed
   rename preserves identity, false on FAT/exFAT under Cygwin/MSYS, SMB noserverino, FUSE
   without use_ino (Lock check hangs on a dataless (cloud-only) pid file when .remember/ lives in a synced folder; every save then reports "another save holds the lock" #1103's own setup). Fixed with a new self-test,
   _lock_rename_preserves_identity, that detects this and falls back to the existing
   content re-read.
3. Hand-back clobber -- every hand-back mv could clobber a pid another process
   legitimately wrote. Fixed with a new _lock_handback helper using noclobber for the
   write.

Two self-review rounds followed (Explore + oss:auditor, spawned independently against
the diff each time, tree_snapshot clean before and after every spawn) and fixed four
further defects the first commit's own fix introduced or left open:

• The identity-probe helper, run inside the lock directory, reset that directory's own
  staleness-tracking mtime on every steal attempt, reopening the save-session.sh: a hung save holds save.lock forever, and every later save is skipped #1101/Lock check hangs on a dataless (cloud-only) pid file when .remember/ lives in a synced folder; every save then reports "another save holds the lock" #1103 outage via
  the helper meant to avoid it. Fixed by moving the probe to the lock directory's parent.
• The hand-back fallback was still a bare unguarded mv, and every call site had
  already attempted its own read. Fixed by threading the already-read content through as
  an optional argument and falling to a guarded (destination-confirmed-absent) restore.
• That same fallback then conflated "no read attempted" with "read succeeded and the pid
  file is legitimately empty," routing a real empty value into the weaker fallback.
  Fixed by testing argument count instead of value emptiness.
• The identity-probe's parent-directory derivation stripped only one trailing slash, so
  a caller-supplied path with a trailing slash got parent == dir, silently reopening
  the mtime-reset finding above for that input shape. Fixed with a portable (bash
  3.2-safe) loop that strips all trailing slashes.

Two low-severity residuals are documented in code comments and logged under trap.d/
rather than fixed, by agreement of both independent reviewers in both rounds, and both
are below-bar:

• trap.d/1124.steal-probe-litter-on-kill.md -- new .steal-probe.* files have no
  reaping logic if a process is killed mid-probe.
• trap.d/1124.handback-fallback-residual-toctou.md -- the guarded-mv fallback itself is
  check-then-act, not atomic; narrower TOCTOU window than the original bare mv, not
  zero. Neither blocks this pull request per both reviewers' judgment in both rounds.

The review loop was stopped after this second self-review round by deliberate judgment
rather than running a third: fix_commit_scope.py still said needs-second-pass (4 files
touched), but both independent reviewers in the second round converged on the same core
finding independently, and the one remaining documented gap (the fallback's own TOCTOU)
was already ranked non-blocking by both reviewers and is the kind of residual this file
already accepts elsewhere (pid-recycling, inode-portability).

Cross-platform claims

• The mtime-reset fix is observed directly on darwin/APFS via the regression test;
  the underlying reasoning (directory-mtime-on-entry-change is POSIX-universal) is
  portable, but this was never run on Linux, Windows, Cygwin/MSYS, or an actual
  FAT/exFAT/SMB/FUSE-without-use_ino mount.
• The premise that rename does not preserve identity on those filesystems is
  reasoned from documentation, never observed on a real instance of any of them --
  this repo's CI matrix (ubuntu-latest/macos-latest/windows-latest, i.e. ext4/APFS/NTFS)
  does not cover any of them either.
• bash 3.2 compatibility of the new trailing-slash-stripping loop is reasoned from
  bash version history, not observed against an actual bash 3.2 interpreter.

Also noted, unrelated to this fix

• lib-lock.sh _lock_try_steal: #1122's inode check ties back to its own pre-steal snapshot, not to the original pid read -- a prior swap can still produce two holders #1125 is a duplicate filed independently by the release process for finding 1 above; a
  duplicate comment was posted on it pointing at this branch, but closing it was denied
  by this session's own permission classifier ("External System Writes") -- it needs to
  be closed manually as a duplicate of Lock takeover: three remaining two-holder/outage paths in _lock_try_steal after #1123 #1124.
• The CI failure in test_recovery_save_stacking_1086.py (macos-latest 3.12, job
  128429537744) was checked and found unrelated: its mechanism is
  session-start-hook.sh's own deferred-pid marker file, which never goes through any
  lock* function in lib-lock.sh.

Closes #1124

🤖 Generated with Claude Code

[AI-generated]